Distributed Object Monitoring for Root Analyses with Go4 V3

The new version 3 of the ROOT based GSI standard analysis framework Go4 (GSI Object Oriented Online Offline) has been released. Go4 provides multithreaded remote communication between analysis process and GUI process, a dynamically configurable analysis framework, and a Qt based GUI with embedded ROOT graphics. In version 3 a new internal object manager was developed. Its functionality was separated from the GUI implementation. This improves the Go4 GUI and browser functionality. Browsing and object monitoring from various local and remote data sources is provided by a user-transparent proxy architecture. The Go4 communication mechanism between GUI and analysis processes was redesigned. Several distributed viewers may now connect to one analysis. Even a standard CINT session may initiate the Go4 communication environment to control an analysis process with the native ROOT browser. Similarly, standard analysis ROOT macros may be controlled by either a remote Go4 GUI or ROOT browser. Besides Linux, a lightweight binary Go4 v3 distribution (without Qt GUI) for MS WindowsXP is now available. Cross platform connections between Go4 environments are possible. GO4 INTRODUCTION The Go4 (GSI Object Oriented Online Offline) software package is well established in the atomic and nuclear-structure physics community at GSI. It is based on the ROOT system [1]. Go4 v3 was released in November 2005 and can be downloaded from the Go4 website [2] under GPL conditions. The Go4 analysis framework applies flexible interface classes for data structures, IO, event processing, and runtime initialization. The analysis can be set up modularly by means of “analysis step” objects. The experiment specific analysis code is written in userdefined subclasses and virtual methods. All ROOT and C++ features may be applied here, thus it is also possible to adapt code from other frameworks. Implementations for the GSI standard DAQ system MBS [3], and ROOT TTree IO are already provided. The same Go4 analysis may either run in batch mode (compiled or as CINT macro), or in an interactive mode controlled by a non blocking GUI. Here analysis and GUI run in separate processes, connected for asynchronous command and data exchange via sockets. This multi threaded inter-task communication is managed by dedicated Go4 libraries [4]. The Go4 GUI was designed by means of the Qt graphics library [5]. It implements regular ROOT Figure 1: Go4 inter-task communication: one analysis server (slave) is connected from several GUI clients (masters). There is only one controller GUI allowed that may modify the analysis set up and running state. graphics inside Qt widgets [6]. A multi document interface (MDI) workspace offers subwindows for object browsing, histogram display, editing, analysis configuration, etc. Moreover, it is possible to extend the standard GUI functionality by experiment specific windows, as defined by the user with the Qt designer tool. To enhance functionality and maintainability, some internal components have been redesigned for Go4 version 3. This mainly concerns the inter-task communication, and the object management of the GUI. NEW DEVELOPMENTS FOR V3.0 Inter-task Communication The design upgrade of the Go4TaskHandler architecture [4] resulted in a decoupling of the client/server functionality from master/slave roles. Thus the analysis can run in the network both as server or client task. Vice versa, the GUI can run either as client or as server. As a benefit, one analysis server can be connected by many Go4 GUIs (Fig.1). A crash of one GUI will simply remove the connection at the server, without affecting the analysis. Moreover, all GUIs may even disconnect from the running analysis completely without shutting it down. A simple account management prevents conflicts of control between the different GUIs. For login of the GUI at the analysis task, there are observer, controller, and administrator accounts. The observer may only request exisiting data and display it, but can not modify data, or change the analysis set-up or running state. The controller may in addition start and stop the run, and change the analysis parameters. Finally, the administrator may even shut down the analysis server completely and thus disconnect all other GUIs. There can be only one controller (or adminstrator) connected to the analysis at the same time. The number of observers is not restricted in principle, but may practically be limited by the performance of the server task. A test was done with 15 GUIs at one analysis, distributed over different nodes, with many permanent monitoring requests from all observers. The analysis server showed to run stable until it was stopped after 3 days. However, analysis event rate dropped by a factor of 3-5 compared to the case with only one GUI. This of course strongly depends on the kind of analysis, and on the number and frequency of requested objects. The changed task handler design made it also possible to use a Go4 analysis server in a regular ROOT CINT session. This is described in more detail in section “distributed monitoring”.